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P  REFACE 


This  Memorandum  describes  a  parsing  capability  em¬ 
bedded  within  the  PL/I  progranming  language.  This  exten¬ 
sion  allows  users  to  specify  the  syntax  of  their  parse 
requests  in  a  BNF-like  language  and  the  semantics  associated 
with  a  successful  parse  request  in  the  PL/I  language. 

The  APAREL  system  has  been  designed  for  a  wide  range 
of  parsing  applications  including  macro  expansion,  symbol 
manipulation,  on-line  command  parsing,  analysis  of  program, 
and  translation  of  progranming  languages. 


-V- 


SUMMARY 


This  Memorandum  describes  APAREL,  an  extension  to  an 
algorithmic  language  (PL/I)  that  provides  the  pattern¬ 
matching  capabilities  normally  found  only  in  special 
purpose  languages  such  as  SN0B0L4  and  IMG.  This  capability 
is  provided  through  parse  requests  stated  in  a  BNF-like 
fort  at.  These  parse  requests  form  their  own  programming 
language  with  special  sequencing  rules.  Upon  successfully 
completing  a  parse  request,  an  associated  piece  of  PL/I 
code  is  executed.  This  code  has  available  for  use,  as 
normal  PL/I  strings ,  the  various  pieces  (at  all  levels)  of 
the  parse.  It  also  has  available  as  normal  PL/I  variables, 
the  information  concerning  which  of  the  various  alternatives 
were  successful.  Convenient  facilities  for  multiple  input- 
output  streams,  the  initiation  of  sequences  of  parse  re¬ 
quests  as  a  subroutine,  and  parse  time  semantic  checks  are 
also  included. 

APAREL  has  prov' a  convenient  in  building  a  powerful 
SYNTAX  and  FUNCTION  macro  system,  an  algebraic  language 
preprocessor  debugging  system,  an  on-line  command  parser, 
a  translator  for  Dataless  Programming,  and  as  a  general 
string  manipulator. 
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I .  INTRODUCTION 

Higher-level  descriptions  of  the  problem  of  compiling 
have  attracted  much  interest  in  the  past  few  years.  Along 
with  the  desire  to  develop  higher-level  specialized  lan¬ 
guages  tailored  to  particular  users,  the  need  has  arisen 
to  develop  similar  specialized  languages  for  the  writing 
of  these  compilers.  In  general,  these  so-called  compiler- 
compiler  languages  are  characterized  by  their  facility  to 
define  in  a  BNF-like  manner  the  syntax  of  the  target  lan¬ 
guage.  In  addJtion,  they  possess  a  programming  language 
designed  to  operate  on  and  to  direct  the  results  of  the 
parsing. 

With  most  compiler-compilers  a  problem  arises  both 
in  controlling  the  parse  sequencing  and  in  operating  on  the 
results  of  the  parsing.  In  particular,  flexibility  is 
usually  lacking  in  1)  the  specification  of  sequences  of 
parse  attempts,  2)  the  determination  of  the  success  or 
failure  of  a  parse  attempt  on  other  than  purely  syntactic 
grounds,  and  3)  the  specification  of  when  semantic  routines 
should  be  invoked.  Furthermore,  the  semantic  language  is 
usually  a  small  special-purpose  language  with  facilities 
for  the  production  of  machine  code.  These  systems  ignore 
such  other,  non-compilation  applications  for  parsers  as 
on-line  conmand  parsers  (which  produce  actions  instead  of 
machine  code) ,  interpretive  parsers  (which  produce  pseudo¬ 
code)  ,  "natural- language"  parsers  (which  produce  semantic 
trees) ,  macro  parsers  (which  produce  source  code) ,  refor¬ 
matting  programs  (which  produce  formatted  listings) ,  and 
so  on.  In  short,  the  non-machine-code  generation  applica¬ 
tions  of  parsers  have  not  been  well  handled  by  the  trans¬ 
lator  writing  systems. 
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APAREL  attempts  to  provide  a  single  system  for  all 
these  applications  by  providing  the  user  with  a  powerful 
general-purpose  programming  language  (PL/I)  for  performir" 
the  wide  range  of  semantics  required,  and  a  flexible  high- 
level  syntax  language  for  specifying  parse  attempts,  to¬ 
gether  with  facilities  for  controlling  the  sequences  of 
these  parse  attempts,  determining  success  and/or  failure 
on  both  syntactic  and  semantic  grounds,  invoking  semantics 
when  desired,  and  for  manipulating  the  parts  of  a  success¬ 
ful  parse.  Also,  the  familiarity  of  programmers  with  PL/I 
and  the  simplicity  of  the  APAREL  extensions  and  additions 
make  it  feasible  for  potential  users  to  design,  implement 
and  modify  special-purpose  languages  without  extensive 
learning . 
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II.  APAREL--A  PARSE-REQUEST  LANGUAGE 

Our  view  of  translation  is  composed  of  three  parts: 

1)  A  request  to  find  sequences  of  syntactic  con¬ 
structs  in  the  source  string  to  be  parsed; 

2)  Context-sensitive  validity  checks  to  be  made 
after  successful  syntactic  parses  (e.g.,  has 
the  label  been  defined  before?  Is  the  type  of 
a  variable  arithmetic?  etc.); 

3)  Semantic  routines  to  be  executed  only  if  both 
the  syntactic  parse  and  the  context-sensitive 
validity  checks  are  successful. 

This  view  of  translation,  while  vety  general,  is  easy 
for  non-professional  translator  writers  (but  experienced 
programmers)  to  use  in  constructing  easily  modifiable 
translators . 

Requests  for  parses  are  specified  in  a  language  very 
similar  to  BNF  rather  than  a  production- type  language, 
because  non-professional  translator  writers  tend  to  con¬ 
ceptualize  the  syntax  of  their  language  top-down  (for  which 
purposed  BNF-type  languages  are  well  suited) .  Professional 
translator  writers,  on  the  other  hand,  have  learned  that 
the  bottom-up  approach  (for  which  production- type  languages 
are  appropriate)  is  usually  more  efficient.  Furthermore, 
they  tend  to  think  of  both  the  syntax  and  semantics  at  the 
statement  level. 

To  keep  the  syntax  language  simple,  while  still  allow¬ 
ing  generality  in  describing  conditions  falling  in  the  hazy 
area  between  syntax  and  semantics  (which  one  would  like  to 
verify  before  accepting  a  parse  made  on  syntactic  grounds 
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aW),  we  allow  the  specification  of  "parse-time"  routines 
thar  return  truth  values.  If  they  return  a  value  of  TRUE, 
the  parse  will  continue.  However,  if  a  value  of  FALSE  is 
returned,  the  parse  will  be  unsuccessful,  just  as  if  the 
syntactic  parse  failed.  (The  total  parse  may  still  be 
successful  if  alternatives  are  available  to  the  unsuccess¬ 
ful  subparse.)  In  addition  to  returning  truth  values,  these 
parse- time"  routines  may  do  any  semantic  processing  de¬ 
sired.  They  are  written  in  the  semantic  language  described 
below. 

The  semantic  routines  are  activated  upon  successful 
completion  of  the  total  parse  and  successful  returns  from 
all  the  relevant  parse-time  validity  checks,  if  any,  speci¬ 
fied  within  the  parse.  The  code  for  the  semantic  routine 
immediately  follows  the  request  for  the  parse  in  the  syntax 
language.  The  semantic  language,  rather  than  being  a  re¬ 
stricted  special-purpose  language,  is  full  PL/I.  The  wide 
range  of  desirable  "semantic"  actions  resulting  from  various 
syntactic  parses  necessitates  a  general-purpose  progranming 
language;  and  a  major  shortcoming  of  most  compiler-compilers 
has  been  their  restrictions  on  the  semantic  language. 

To  facilitate  the  semantics,  the  various  pieces  of  the 
successful  parse  are  put  into  normal  PL/I  strings  as  speci¬ 
fied  in  the  syntax  language;  and  the  options  chosen,  where 
alternatives  were  specified  in  the  syntax  language,  are 
made  available  in  normal  PL/I  variables. 

DESCRIPTION  OF  PARSE— REQUESTS 

The  syntax  of  the  parse-request  language,  specified  in 
BNF,  appears  in  Appendix  I.  However,  the  following  examples 
are  used  to  describe  the  language  informally. 
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All  parse-requests  begin  and  end  with  a  parse-delimir ~ 
ator  (a  double  colon).  After  the  beginning  delimi  lator , 
the  name  of  the  request  (the  parse-name)  is  set  off  by  a 
colon.  The  remainder  of  the  parse-request  is  a  list  of  the 
alternative  parses  (parse_alternati.ve_list)  desired,  sep¬ 
arated  by  OR  (j)  symbols.  The  parse-request  is  successful 
if  any  one  of  the  alternatives  is  successfully  parsed. 

These  alternatives  may  be  either  parse-elements  or  lists 
of  parse-elements.  Letting  PE^  represent  a  set  of  parse- 
elements,  we  can  describe  the  following  parse  requests: 

(the  parse-request  named 
"A"  will  s'icceed  if  and 
only  if  the  parse-string 
contains  PE^  following  PE2) 

(the  parse -request  named 
’■B"  will  succeed  if  and 
only  if  the  parse- string 
contains  either  PEj  or  PE2) 

(the  parse-request  named 
"C"  will  succeed  if  and 
only  if  the  parse-string 
contains  cither  PE^  or 
the  sequence  PE2PE^PE^) 

The  parse-elements  can  either  be  a  parse-group  or  a 
parse-atom.  A  parse-group  is  simply  a  named  or  un-named 
parse-alternative  list  enclosed  in  brackets  ("("  and  ">") , 
allowing  naming  of  parts  of  a  parse  and  alternatives  with¬ 
in  a  sequence  of  parse-elements.  Tlie  parse-atoms--the 


• •  A  •  PF  PF  •  • 
•  •  *»  •  •  • 


: :  B:  PE. |PE0  : : 

i. 1  2 


::  C:  PEr |PE2PE3PF-4  :: 
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basic,  indivisible  components  of  a  parse-request--consist 
of  iteral  strings,  parse-request  names,  and  primitive 
functions;  e.g. ,  ARBNO  (arbitrary  number  of),  and  BAL 
(balanced  strings) .  These  atoms  are  the  components  that 
determine  whether  a  parse  is  successful  or  not.  The  literal 
strings  require  that  an  exact  match  be  found  between  the 
literal  and  the  corresponding  piece  of  the  parse-string; 
the  parse-request  names  require  that  the  named  parse- 
request  be  successful  on  the  corresponding  piece  of  the 
parse-string;  and  primitive  functions  require  that  the 
corresponding  piece  of  the  parse-string  satisfy  the  condi¬ 
tions  of  that  particular  function.  There  is  no  syntactic 
distinction  made  between  these  atoms.  The  category  de¬ 
termination  is  male  in  the  following  way.  First,  the  list 
of  primitive  functions  is  checked.  If  the  atom  is  not  a 
primitive  function,  then  the  list  of  parse-names  is  checked. 
Finally,  if  it  is  not  one  of  these,  it  is  considered  to  be 
a  literal.  This  mechanism  alleviates  the  need  to  quote 
most  literals  within  the  par ~e- request  language. 

Consider  the  following  set  of  parse-requests  to  parse 
PL/I  DO  statements: 

::  do_statement :  do  iterative_specification 
while_clause  ' ; '  : : 

: :  iterative_specification:  (variable  =  expression 
(to_clause  by_clause |by_clause  to_clause) ) | : : 

::  to_clause:  to  expression]:: 

::  by_clause:  by  expression):: 

::  while_clause :  while  '('expression')'!:: 

The  do_statement  request  requires  the  sequence  of 


atoms 
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do  iterative_specification  while_clause  ; 

in  the  parse-string  to  be  successful.  Of  these,  the  middle 
two  are  parse-names  and  invoke  parse-requests  as  they  are 
encountered  in  a  left  to  right  scan.  The  first  and  last 
atoms  are  literals  (because  they  are  not  defined  as  parse- 
names  or  primitive  functions) ,  and  require  exact  matches 
with  a  piece  of  the  parse-string.  The  final  atom  is  quoted 
because  semicolons  are  part  of  the  parse -request  language 
(explained  below) ,  and  the  semicolon  here  is  used  as  a 
literal. 

The  iterative_specif ication  request  requires  the 
sequence: 

1)  Variable_expression 

2)  either  2a.  to_clause 

2b.  by_clause 

or  2a.  by_clause 
2b.  to_clause 

Variable  and  expression  are  primitives,  a.id  are  defined  as 
specified  in  the  PL/I  language  specification  [1].  Sim¬ 
ilarly,  a  to_clause  is  the  literal  "to"  followed  by  an 
expression,  or  is  null,  and  a  while_clause  is  the  literal 
"while"  followed  by  an  expression  enclosed  in  parentheses 
(quoted  because  they  are  part  of  the  syntax  language  and 
are  used  here  as  literals) ,  or  is  null. 

Thus,  the  do_statement  parse-request  invokes  parse- 
requests  for  iterative_specification  and  while_clause ,  and 
iterative_specification  invokes  parse__requests  for  to_clause 
and  by_clause  and  functions  calls  for  variable  and  expression. 

Unless  otherwise  specified,  the  parses  allow  an  arbi¬ 
trary  number  of  blanks  (including  none)  between  atoms,  and 


-8- 


require  the  parse  start  at  the  beginning  of  the  parse¬ 
string  although  i.  may  be  satisfied  before  the  end  of  the 
parse-string.  Thus,  with  the  above  set  of  parse-requests, 
successful  parses  will  occur  on  the  following  parse-strings: 


do  I  ■  1; 

do  I  =  1  by  5  to  (n-3/2)  ; 

do; 


do  while  (A<B) ; 


and  will  fail  wn  the  following  parse-strings: 


I  ■  1  to  10: 

Now  do  I  =  1; 
do  I  =  1  to  5 
do  I  =  1  to  5  to  6; 


(no  initial  do) 

(no  initial  do) 

(no  semicolon) 

(to__clause  followed  by  to_clause) 


The  portion  of  the  parse-request  language  described  so 
far  allows  fairly  sophisticated  parse-requests  to  be  speci¬ 
fied  easily  and  naturally  in  a  language  similar  to  the 
normally  used  syntax  description  languages  (BNF  or  IBM's 
syntax  notation).  However,  thij  is  not  yet  a  useful 
facility,  because  neither  the  sequencing  rules  for  initiating 
parse-requests  and  for  making  sequencing  decisions  based 
upon  the  success  or  failure  of  a  parse-request,  nor  the  method 

of  accessing  the  various  parts  of  a  successful  parse  have  been 
defined. 


PARSE-REQUEST  SEQUENCING  RULES 

A  parse-request-sequence  is  composed  of  all  parse- 
requests  occurring  in  a  common  do-group  or  block.  This  does 
not  include  any  parse-requests  contained  in  blocks  or  do- 
groups  within  the  coranon  do-group  or  block  forming  parse- 
request-sequences  of  their  own.  The  order  of  parse-requests 
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within  a  parse-request- sequence  is  the  same  as  their  lexi¬ 
cographical  ordering  in  the  block  or  do-group.  The  semantic 
portion  of  a  parse-request  is  the  code  between  the  end  of 
the  syntax  portion  of  the  parse-request  and  the  beginning 
of  the  next  parse-request  in  the  parse-request-sequence,  or 
the  end  of  the  do-group  or  block  if  there  are  no  more  parse- 
requests  in  the  sequence. 

A  parse-request  sequence  begins  with  the  first  parse- 
request.  If  the  initial  parse-request  fails,  its  semantic 
code  portion  is  skipped,  and  the  next  parse-request  in  that 
sequence  is  tried,  and  so  on,  until  either  a  successful 
parse-request  is  found  cr  all  parse-requests  fail.  If  a 
successful  parse-request  is  found,  the  associated  semantic 
code  portion  is  executed;  then,  normally,  the  parse-request- 
sequence  is  terminated  with  a  successful  indication  (see 
Sec.  V,  Additional  Features).  Otherwise,  the  parse-request- 
sequence  is  terminated  with  an  unsuccessful  indication. 

T*-ere  are  three  ways  in  which  a  parse-request-sequence 
can  be  initiated.  The  first  is  as  a  parse-atom  in  a  parse- 
request.  Upon  termination,  its  success-failure  indicator 
is  used  in  determining  which  alternatives,  if  any,  are 
successfully  parsed.  The  second  is  through  use  of  an  ex¬ 
plicit  command,  INITIATE  PARSE,  which  specifies  which  parse- 
request-sequence  to  initiate  and  can  be  issued  in  any  code 
portion.  Upon  termination  of  the  parse-request-sequence, 
its  success  or  failure  is  available  (see  Sec.  Ill,  Parse’ 
Results) ,  and  control  continues  with  the  statement  following 
the  INITIATE  PAPSE  comnand.  The  third  method  is  by  program 
control  flowing  into  the  first  parse-request  in  a  parse- 
request-sequence.  Upon  completion  of  the  parse-request- 
sequence,  its  success  or  failure  is  available,  and  control 
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passes  to  the  end  statement  at  the  end  of  the  do-gioup  or 
block  in  which  the  parse-request- sequence  occurs.  Thus, 
if  it  is  contained  in  an  iterative  do-group,  control  will 
continue  around  in  the  loop  until  iteration  is  complete. 
Otherwise,  in  blocks  or  non-iterative  do-groups,  control 
will  flow  out  the  bottom  of  the  block  or  do-group  upon 
termination  of  the  parse-request-sequence. 

In  the  first  two  cases,  where  a  parse-request-sequence 
is  explicitly  named,  it  is  specified  by  referring  to  the 
label  of  the  do-group  or  block  in  which  the  parse-request- 
sequence  occurs.  If  the  name  of  a  parse-request  is  speci¬ 
fied  instead,  only  that  parse-request  will  be  initiated, 
and  no  others  in  its  parse-request-sequence. 

These  sequencing  rules  allow  the  creation  of  sequences 
of  parse-requests  to  be  attempted,  and  the  control  of  the 
execution  order  of  these  requests  based  on  the  results  of 
the  parses  and/or  explicit  program  control. 
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III.  PARSE  RESULTS 


APAREL  also  contains  capabilities  to  make  the  results 
of  a  successful  (or  unsuccessful)  parse  available  to  the 
code  portions  of  the  language.  This  information  is  of  two 
kinds:  pieces  of  the  string  parsed  and  information  about 
which  alternatives  were  successful  in  the  parse. 

Various  parse-elements,  such  as  parse-request-sequences, 
parse-requests ,  parse-olternatives ,  and  parse-groups,  can 
have  names  specified  in  APAREL.  These  names  are  the  means 
by  which  the  semantic  code  portions  can  utilize  information 
about  a  parse.  If  "NAME”  is  the  name  of  one  of  these  parse- 
elements,  then  after  a  parse,  a  PL/I  varying  length  string 
variable  with  the  same  name  will  contain  that  portion  of 
the  parse-string  corresponding  to  the  named  parse-element, 
and  a  PL/I  variable,  whose  name  is  "NAME_OPTION"  (i.e. , 
"_OPTION"  is  appended  to  the  end  of  the  name  of  the  parse- 
element)  ,  will  contain  the  index  of  the  alternative  selected 
within  the  parse-element.  Thus  the  semantic  portions  can 
manipulate  desired  portions  of  the  parse-string  through 
PL/I’s  normal  string-handling  capabilities,  and  can  inter¬ 
rogate  any  portion  of  the  parse- tree  to  determine  which 
alternatives  were  selected. 

In  applications  with  large  syntax  specifications, 
changing  the  syntax--either  by  addition  or  deletion  of  an 
alternative  from  the  syntax--can  affect  the  semantics,  be¬ 
cause  alternative  determination  is  made  on  an  indexed  basis; 
and  altering  the  syntax  alternative  alters  the  indexing. 

To  alleviate  the  problem,  APAREL  allows  the  user  to  label 
any  or  all  of  the  alternatives.  If  a  labeled  alternative 
is  selected,  then  the  OPTION  variable  for  that  group  will 
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contain  the  name  of  the  alternative  selected  rather  than 
its  index.  This  naming  correspondence  is  invariant  under 
additions  or  deletions  to  the  set  of  alternatives. 
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IV.  PARSE -TIME  ROUTINES 


Sometimes  success  or  failure  of  a  parse  cannot  be  made 
on  purely  syntactic  grounds  alone;  or,  it  is  desired  to  per¬ 
form  some  semantic  operations  during  a  parse.  For  these 
reasons,  the  parse-tire  facility  has  been  included  in  APAREL. 
Parse-time  routines  are  indicated  in  a  parse-element  by 
placing  the  parse-time  routine  name  followed  by  its  argu¬ 
ments,  if  any,  enclosed  in  parentheses  after  a  semicolon 
at  the  end  of  the  parse-element.  The  parse-time  routine 
"fill  be  initiated  if  and  only  if  the  parse -element  in  which 
it  occurs  was  successfully  parsed.  The  initiation  results 
in  a  function  call  of  the  parse-time  routine  passing  its 
arguments,  if  any.  The  parse-time  routine,  like  the  semantic 
portions  of  APAREL,  is  coded  in  full  PL/I  and  can  make  use 
of  all  the  facilities  of  APAREL,  such  as  initiating  parse- 
requests,  manipulating  parse-strings,  and  interrogating  the 
parse-trees.  In  addition,  the  parse-time  routine  can  per¬ 
form  any  semantics  desired  and  return  a  true  or  false  value 
indicating  whether  the  parse-element  it  is  attached  to  should 
be  considered  successfully  parsed  or  not. 

Note  that  since  parse-request-sequences  initiated  in  the 
syntactic  portion  of  a  parse  can  be  a  block  or  a  do-group 
that  may  begin  with  a  code  section  or  may  not  contain  any 
parse-requests  at  all,  these  parse-request-sequences  can  be 
considered  parse-time  routines  that  return  a  success  or 
failure  indication  (and  are  formally  the  same  as  the  parse¬ 
time  routines  discussed  above).  Both  ways  of  specifying 
these  parse-time  routines  have  been  allowed  in  APAREL,  en¬ 
abling  users  to  choose  the  one  corresponding  to  their  way 
of  conceptualizing  its  function  in  their  particular 
application. 
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v»  ADDITIONAL  FEATirRR.q 


In  the  semantic  portions  of  APAREL,  very  often  one 
would  like  to  output  a  modified  or  ‘’translated"  version  of 
the  parse-string.  To  make  this  operation  simpler,  a  special 
variable,  TRANSLATION ,  has  been  defined;  and  whenever  an 
assignment  is  made  to  this  variable,  the  value  assigned  is 
output  to  the  SYSPRINT  data  set.  For  more  flexibility,  the 
user  may  define  additional  variables  as  being  output  vari¬ 
able  of  specified  size  and  associated  with  a  specified  file. 
When  an  assignment  is  made  to  one  of  these  variables,  if  the 
value  can  be  added  to  the  end  present  string  v,-  lue  without 
exceeding  the  maximum  size  of  the  variable,  then  the  new 
value  is  concatenated  onto  the  existing  value.  If  not, 
then  the  existing  value  is  output  on  the  file  specified  and 
the  new  value  becomes  the  value  of  the  variable.  If  the 
size  is  not  specified,  then  outputting  occurs  with  every 
assignment.  If  neither  a  file  nor  a  size  is  specified,  then 
a  user-defined  procedure  of  the  same  name  as  the  output 
variable  is  called  with  the  new  value  as  the  argument.  This 
allows  the  user  to  define  arbitrarily  complex  procedures  for 
outputting,  and  corresponds  to  the  updating  routine  (left- 
hand  s.ze  function)  definitional  capability  of  Oataless 
Programing  [2]  and  CPL  [3]. 


Similarly,  for  input,  a  variable,  PARSE_STRING  will 
be  automatically  defined  to  hold  the  input  to  be  parsed. 
When  the  amount  of  input  in  this  variable  falls  below  a 
system-defined  limit,  new  input  will  be  concatenated  to 
the  variable  to  fill  it  out  to  its  maximum  size.  The  user 
may  define  additional  input  variables  together  with  their 
minimum  sizes,  maximum  sizes,  and  file  from  which  input  is 


-15- 


to  come.  If  the  minimum  and  maximum  sizes  are  not  specified, 
references  to  the  input  variable  will  invoke  a  user-defined 
accessing  function  of  arbitrary  complexity,  a  la  Dataless 
Programming. 

The  user  also  can  control  which  of  several  input  sources 
is  used  via  the  CONSIDER  command.  He  may  later  re-establish 
an  input  source  via  the  RECONSIDER  command. 

In  parsing  there  are  normally  three  requirements  for 
blank  separation  between  elements  in  the  parse-string.  The 
first  is  that  no  blank  may  occur  between  the  elements.  This 
is  indicated  in  a  parse-request  by  placing  a  minus  sign  be¬ 
tween  the  elements.  The  other  two  normal  blank-separation 
requirements  are  that  either  any  number  of  blanks  (perhaps 
none) ,  or  at  least  one  blank  (perhaps  more) ,  separate  the 
elements.  Since  the  need  for  each  of  these  requirements 
is  highly  application  dependent,  APAREL  allows  the  user  to 
define  the  normal  mode  (indicated  in  the  parse-request  by 
separating  the  elements  by  at  least  one  blank)  and  to  re¬ 
quest  the  other  requirement  by  placing  a  period  between  the 
elements.  The  normal  mode  is  set  by  either  NORMAL  SEPARATION 
IS  0  or  NORMAL  SEPARATION  IS  1  commands.  The  default  setting 
is  NORMAL  SEPARATION  IS  1. 

Similarly,  the  two  normal  ways  to  view  the  semantic  code 
portion  are  either  as  open  or  closed  subroutines.  In  an 
open  subroutine,  flowing  out  of  the  bottom  of  a  semantic  code 
portion  into  a  parse-request  initiates  that  parse-request. 
Whereas  in  a  closed  subroutine,  flowing  out  the  bottom  of  a 
semantic  code  portion  into  a  parse-request  effects  a  return 
to  the  caller  of  the  parse-request  whose  semantics  have  just 
completed.  APAREL  allows  a  user  to  define  which  of  these 
two  modes  he  is  using  via  the  SEMANTICS  OPEN  and  SEMANTICS 
CLOSED.  The  default  setH  ;  is  SEMANTICS  CLOSED. 
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Bo  th  the  SEPARATION  and  SEMANTICS  commands  are  com¬ 
pile-time  commands  and  affect  the  interpretation  of  all 
lexicographically  following  parse-requests  in  the  current 
or  contained  blocks  or  do-groups,  until  either  the  end  of 
the  block  or  do-group,  or  another  mode  command,  overrides 
the  present  normal  mode . 

Within  a  semantic  code  portion ,  the  user  may  desire 
to  initiate  a  remote  parse-request,  or  to  terminate  the 
semantics  for  the  present  parse.  These  capabilities  are 
available,  respectively,  through  the  INITIATE  PARSE  and 
TERMINATE  PARSE  commands. 

The  TERMINATE  PARSE  command  is  also  used  to  specify 
the  success  or  failure  of  a  parse-request.  TERMINATE  PARSE 
SUCCESSFULLY  indicates  a  successful  termination,  while 
TERMINATE  PARSE  UNSUCCESSFULLY  indicates  an  unsuccessful 
parse.  TERMINATE  PARSE  with  neither  operand  specified  de¬ 
faults  to  TERMINATE  PARSE  SUCCESSFULLY.  Thus,  a  parse- 
request  can  be  declared  unsuccessful  in  three  ways:  1)  in 
the  syntactic  specification  of  the  parse-request  when  a 
syntactic  parse  is  unsuccessful;  2)  in  a  parse- time  routine; 
or  3)  in  the  semantics  of  a  parse-request.  The  parse  is 
successful  only  if  none  of  these  indicate  an  unsuccessful 
parse . 

When  initiating  a  remote  parse-request- sequence  within 
a  semantic  code  portion,  a  user  often  wishes  to  be  able  to 
inspect  and  manipulate  the  results  of  the  parse-requests 
before  accepting  any  translation  produced.  Since  these 
parse-requests  should  not  (and  need  not)  know  that  they 
have  been  initiated  from  above,  they  must  be  able  to  create 
translations  just  like  any  other  parse-request.  Therefore, 
the  user  needs  a  way  of  telling  APAREL  to  redirect  the 
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translation  (or  output  variables)  of  any  parse-request. 

This  redirection  causes  the  translation  produced  for  the 
specified  output  variables  to  be  collected  into  the  speci¬ 
fied  strings  for  review  and/ or  manipulation  by  the  initiating 
routine.  This  redirection  is  specified  as  additional  oper¬ 
ands  to  the  initiate  parse -command  as  follows: 

INITIATE  PARSE  k  COLLECTING  translation  IN  s  AND 
output  IN  def; 

The  parse-request- sequence  named  k  will  be  initiated.  All 
translation  it,  or  any  parse-request  it  initiates,  produces 
in  the  output  variable  named  "translation"  will  be  collected 
in  the  string  named  "s",  ana  all  translation  produced  in  the 
output  variable  named  "output"  will  be  collected  in  the 
string  named  "def". 

Finally,  by  placing  a  dollar  sign  ($)  in  front  of 
parse-names,  parse-time  routine  names,  or  parse-atoms,  the 
user  can  indicate  indirection;  i.e.,  the  parse-name,  parse- 
routine  name,  or  parse-atom  specified  is  the  contents  of 
the  named  string.  This  facility  provides  considerable 
flexibility  for  users  desiring  to  alter  the  parse-requests 
dynamically.  It  also  facilitates  context-sensitive  parses 
requiring  repetition  of  a  parse-o.lement  within  the  input 
string. 
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VI .  EXAMPLES 


One  use  of  APAREL  is  as  a  macro  processor,  handling 
macros  of  the  type  commonly  referred  to  as  SYNTAX  and/or 
FUNCTION  macros  [4].  In  such  an  application,  a  user  passes 
the  macros  over  the  sc  nrce  text,  translating  those  portions 
that  satisfy  the  macro  syntax  while  leaving  the  rest  of  the 
text  undisturbed.  APAREL  is  easily  restricted  to  this  mode 
by  defining  a  parse-request  that  picks  off  source-language 
statements,  one  at  a  time,  from  the  input  stream.  The 
result  of  this  parse,  a  single  source-language  statement, 
is  then  passed  through  the  various  macros  that  produce  the 
desired  translation  when  a  parse  request  for  a  macro  is 
satisfied.  If  the  source  statement  passes  all  the  way 
through  the  macros  without  matching,  it  is  output  unmodified. 
Assuming  the  parse-request,  PL__statement ,  has  been  pre¬ 
defined  and  will  pick  off  one  PL/I  statement  at  a  time,  the 
following  is  an  APAREL  program  that  acts  as  a  SYNTAX  and 
FUNCTION  macro  processor  for  any  parse-requests  defined  in 
its  body. 

next_PLl_statement : 

INITIATE  PLl_statement ;  /*  get  next  PL/I  statement*/ 

IF  PLl_statemem._option  =  0  /*  was  the  parse  successful*/ 
THEN  DO;  /*  no,  end  of  input  must  have  been  reached*/ 
IF  CONSIDERED_STRING  (CONSIDERJLEVEL)  =  ' rescan  ' 
THEN  DO;  /*reconsider  the  original 
input  string*/ 

RECONSIDER; 

GO  TO  next_PLl_statement ; 

END; 
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ELSE  /*  we  have  exhausted  the  original  input 
string*/ 

TERMINATE  PARSE;  /*  terminate  the  parse 
in  this  manner  in  case  we  were 
initiated  by  someone,  and  are  not 
the  top  level  routine*/ 

END; 

ELSE  DO;  /*  parse  was  successful,  we  now  have  a  single 

PL/I  statement*/ 

CONSIDER  PLl_statement ;  /*  use  result  of  PL/I  statement 

as  parse- string*/ 

INITIATE  user_macros  COLLECTING  translation  IN  partial_ 

translation;  /*  initiate  users 
syntax  and  function  macro  parse- 
request-sequence  contained  in  the 
block  or  do_group  labeled  "user- 
macros".  The  translation  output 
of  these  macros  is  collected  in 
the  PL/I  string  "partial_trans- 
lation"*/ 

If  user_macros_optiorr-i  =  0  THEN  DO;  /*  one  of  the  parse- 

requests  in  the  user_macros  parse- 
request-sequence  was  successful*/ 
RECONSIDER;  /*  stop  considering  PLl_statement  and 
reconsider  the  parse-string  in 
effect  before  it*/ 

rescan  =  partial_translation | | rescan ;  /*  add 

partial  translations  to  front  of 
rescan  string  so  that  it  will  be 
retranslated  first.  Notice  that 
this  defines  a  depth  first 
translation*/ 
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IF  CONSIDERED_STRING  (CONS IDE R_LEVEL)-i  =  'rescan' 

/*  is  rescan  the  currently  considered 
parse-string*/ 

THEN  /*  no  it  is  not  the  currently  considered 
string*/ 

CONSIDER  rescan;  /*  make  it  the  current 
parse-string*/ 

GO  TO  next_PLl__statement ; 

END; 

ELSE  DO;  /*  none  of  the  parse-requerts  in  the  user_macros 

parse-request-sequence  were  successful*/ 
TRANSLATION  =  PLl_statement ;  /*  output  the 

PLl_statement  that  did  not  match*/ 

GO  TO  next_PLl__ statement; 

END; 

Continuing  the  above  example ,  two  parse-requests  are 
shown  below,  both  of  which  provide  translations  into  Pl/I. 

They  are  placed  in  the  do_group  labeled  '  user_macros"  to 
conform  to  the  preceding  exarple/s  initiation  conroand.  The 
first  is  a  syntax  macro  that  translates  increment  or  decrement 
commands,  and  the  second  is  a  functional  macro  that  trans¬ 
lates  various  notations  for  asking  if  a  value  is  equal  to  one 
of  a  number  of  items.  Notice  that  the  only  difference  be¬ 
tween  syntax  and  function  macros  is  that  syntax  macros  re¬ 
quire  successful  parses  to  be  anchored  to  the  beginning  of 
the  parse-string,  while  functional  macros  allow  successful 
parses  anywhere  within  the  parse-string. 

The  annotated  parse-requests  are  given  below,  followed 
by  a  set  of  example  input  parse-strings  with  their  trans¬ 
lations  : 
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user_macros:  DO;  /*  begin  labeled  do  group  that  defines  a 

parse  sequence*/ 

NORMAL  SEPARATION  IS1;  /*  unless  otherwise  specified, 

parse-elements  must  be  separated 
by  one  or  more  blanks*/ 

SEMANTICS  CLOSED;  /*  upon  reaching  the  end  of  the 

semantics  of  a  parse-request, 
automatically  generate  a  terminate- 
parse  command*/ 

::  Increment_command :  command_type  (updated_variable : 

subscripted_variable)  by  <increment_ 
amount:  ARB).';'  ::  /*  an  increment 
command  is  a  command  type  followed 
by  a  possibly  subscripted  variable, 
called  "updated_variable" ,  followed 
by  the  literal  "BY"  (literal  since 
it  is  not  defined) ,  followed  by  an 
arbitrary  string  called  "increment_ 
amount",  followed  by  a  semicolon 
(the  semicolon  has  to  be  quoted 
since  it  is  part  of  the  parse- 
request  language).  The  period 
indicates  that  a  space  is  not  re¬ 
quired  in  front  of  the  semicolon.*/ 
IF  command_type_option  =  "increment_command"  /*  was  the 

option  in  command_type  labeled 
"increment_command"  chosen*/ 

THEN  /*  yes  this  is  an  increment  command*/ 

translation  *  updated_variable 1 j ' = ' | |updated_ 
variable | ] '+' | | increment-amount 
| )  * ;  *  ;  /*output  PL1  assignment  for 
incrementing  variable*/ 
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ELSE  /*  no,  must  be  decrement  command*/ 

translation  =  updated_var table  |  |  |  |updated__ 

variable | | ' - ( ' | | increme nt_amount 
/*output  PL/I  assignment 
for  decrementing  variable  enclosing 
increment_amount  in  parenthesis*/ 

/*  the  next  statement  is  a  parse-request  in  the  same 

block  or  do  group  as  the  present 
parse-request;  therefore,  it 
indicates  the  end  of  this  semantic 
code;  and  since  semantics  have  to 
be  set  closed,  it  automatically 
generates  a  terminate-parse 
command.*/ 

/*  this  parse-request  will  be  activated  if  the  preceding 

parse-request  failed*/ 

one_of: (front : ARB) (x:  subscripted_variable> (is | is  among |.=.) 

alternative_list (back: ARB) : : 

/*  a  one_of  function  macro  is  an 
arbitrary  string  named  "front" 
followed  by  a  subscripted  variable 
named  "x"  followed  by  either  "is", 

"is"  followed  by  "among",  or  by 
This  is  followed  by  an  alternative_ 
list  followed  by  an  arbitrary  string 
named  "back".  The  separation  between 
these  elements  is  one  or  more  blanks-- 
except  for  the  equal  sign,  which  may 
have  zero  or  more  blanks  on  either 
side  of  it  as  indicated  by  the  normal 
separation  override  notation  (the 
periods) .*/ 
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translation  =  front | | PLl_alternatives | (back;  /*the 
string  "PLl_alternatives"  replaces 
the  function  macro  in  the  parse¬ 
string,  and  the  result  is  output  as 
the  translation  of  the  parse-string. 
The  PLl_alternatives  string  was 
built  up  in  the  semantic  portion  of 
the  alternative_list  parse-request 
shown  below*/ 

END  user_macros;  /*  this  is  the  end  of  the  do-group. 

It  indicates  the  end  of  the  semantic 
portion  of  the  one__of  parse-request; 
and,  since  semantics  are  closed, 
automatically  generates  a  terminate 
parse-command  for  that  parse-request. 
If  this  parse-request  had  failed, 
then,  since  it  was  the  last  parse- 
request  in  the  parse-request-sequence, 
the  sequence  would  have  failed.*/ 

/*  the  following  are  parse-requests  referred  to  above. 

Since  they  are  defined  in  another 
do-group  or  block  than  the  preceding 
parse-requests,  they  do  not  form 
part  of  its  parse-request-sequence.*/ 
subscripted_variable:  variable  BAL /*a 

subscripted  variable  is  a  variable 
followed  by  a  left  parenthesis 
followed  by  an  arbitrary  string 
balanced  with  parentheses  followed 
by  a  right  parenthesis  or  a  variable 
followed  by  a  null.  The  parentheses 
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and  the  balanced  string  do  not  have 
to  be  separated  by  blanks.  There 
are  no  semantics  specified  for  this 
parse-request.*/ 

command_type :  <inc remen t_command:  increment | i | inc) | 

<decrement_command:  decrement |d | dec) : : 
/*  a  command  type  is  either  an 
increment_command  or  a  decrement_ 
command.  These  two  types  can  each 
be  indicated  in  one  of  three  ways : 
"increment",  "i";  or  "inc"  and 
"decrement",  "d";  or  "dec".  There 
are  no  semantics  specified  for  this 
parse-request  */ 

alternative_list :  Initial_semantics  B0UND(1, alternative , 

<  * , * |  or  >)  ::  /*  an  alternative_ 

list  is  an  initial_semantics  followed 
by  an  arbitrary  number  (with  a 
minimum  of  one)  of  alternatives 
separated  by  either  commas  or  the 
literal  "or”.  The  parse-request, 
initial_semantics ,  does  not  perform 
any  parsing,  but  is  used  co  initial¬ 
ize  the  string,  PLl_alternative , 
used  in  the  semantics  of  "alterna¬ 
tive".  There  are  no  semantics 
specified  for  this  parse-request.*/ 

alternative:  expression:  /*  an  alternative  is  an  ex¬ 
pression.  Its  semantics  follow. 

The  same  effect  could  have  been 
achieved  by  replacing  alternative 
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in  the  parse-request  alternative_lis t 
by 

expression;  altemative_semantics 
where  alternative_semantics  would  be 
the  name  of  the  following  semantic 
routine.  The  choice  is  left  to  the 
user  depending  on  his  particular 
basis .*/ 

if  -i  first_alternative  then  PLl_alternatives=PLl_ 

alternatives | | ' | |x ! | '=' | I  expression; 
/*  the  alternative  is  added  to  the  end 
of  the  alternatives  already  found. 

It  is  separated  from  the  preceding 
alternatives  by  and  consists  of 

the  subscripted  variable  (the  value 
of  x  from  the  parse-request,  "one_of") 
followed  by  an  equal  sign  followed 
by  an  expression  just  parsed  above.*/ 
ELSE  DO;  /*  this  is  the  first  alternative*/  first_ 

alternative  =  'O’B;  /*  indicate  no 
longer  first  alternative*/ 
PLl_alternatives  =  x|j'='|i  expression; 
/*  PLl_alternatives  is  set  to  the 
first  alternative  found*/ 

END; 

TERMINATE  PARSE;  /*  indicate  end  of  semantics*/ 
initial_semantics :  DO;  /*  initial_semantics  is  a  parse-request- 

sequence  containing  no  parse -request*/ 
f irst_alternative  =  1 1  *  B ;  /*  indicate  parse-request  was 

successful*/ 


END; 
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VII.  TRANSLATION  RESULTS 

Using  the  APAREL  program  defined  in  Sec.  VI,  we  indi¬ 
cate  below  the  translations  that  would  result  for  various 
input  examples.  If  the  input  passes  through  unchanged,  the 
translation  entry  is  left  blank  to  facilitate  recognition. 


i  def  by 7; 


decrement  by  3; 


if  abc  is  x-3  or 
0  then  do; 

R  =  (def  is  among 
1,2  ,Z-4  or  9) ; 


translation 
x  =  x+5 

abc  =  abc  -  (x-4) ; 


if  abc  =  x-3  | 
abc  =  0  then  do; 

R  =  (def  =  1  j  def  =  2 
|  def  *  Z-4  j 
def  *  9) ; 


comments 

the  decrement 
translation 
supplies  paren¬ 
theses  around  the 
dec  re men  t  amoun  t . 
no  separating 
blank  after  'by' 

'by'  is  picked 
up  as  the  sub¬ 
scripted  variable, 
but  the  parse  then 
fails  because  'by' 
cannot  be  found. 
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input 

when  h  =  5 ,  or 
then  do; 


if  x  is  3 ,>5 , 

if  x  =  1  or  4 
then  i  x  by 


7 


translation 


when  h  =  5  j  h  =  or 
7  then  do; 


or  0 


x-1; 


if  x  =  1 
then  x 


x  =  4 
x+x-1; 


comments 

comma  after  5 
causes  parser 
to  pick  up  "or" 
as  an  expression 
rather  than  as  the 
separator  between 
expressions.  The 
syntax  of  the 
functional  macro 
should  be  cor¬ 
rected  to  prevent 
this  error.  Notice 
how  the  error  is 
reflected  in  the 
translation; 

">5"  is  not  an 
expression. 
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VIII.  IMPLEMENTATION 

Implementation  of  APAREL  was  of  course  affected  by  the 
desirability  of  using  PL/I  as  the  basic  Language  for  expres¬ 
sing  the  semantic  operations.  PL/I  was  chosen  because  of 
its  power  and  familiarity.  At  the  same  time,  it  was  decided 
that  the  actual  parsing  be  implemented  as  an  interpreter. 

This  necessitated  that  the  parse-request  language  of  APAREL 
be  translated  into  an  interpretable  structure.  The  benefits 
gained  from  the  simplicity  and  extendability  of  this  approach 
aie  considered  worth  the  price  of  translation. 

APAREL  is  a  two-pass  processor  that  first  translates  the 
APAREL  program  into  an  interpretive  program  for  driving  the 
parser  and  then  crosscouples  the  results  of  the  parse  with 
the  semantic  section  of  the  user's  program.  Two  passes  are 
necessary  because  of  certain  limitations  of  PL/I,  in  which 
APAREL  is  programmed.  The  main  limitation  is  the  inability 
to  dynamically  define  equivalences,  at  least  in  the  PL/I 
DEFINED  context. 

The  heart  of  APAREL  is  an  interpretive  representation  of 
the  parse-request.  The  structure  cf  the  interpretive  list 
and  other  internal  details  are  described  below. 

The  problem  of  relating  APAREL  names  with  PL/l  variables 
has  been  solved  by  twice  examining  the  parse-request.  The 
first  is  done  in  a  pass  over  the  APAREL  program.  The  main 
purpose  of  this  pass  is  to  form  a  symbol  ta^le  identical  with 
that  used  during  execution.  This  symbol  table  will  be  used 
at  run  time  to  hold  (among  other  things)  the  current  values 
of  named  items.  The  result  of  the  first  pass  is  to  output, 
for  compilation  by  PL/I,  a  modified  APAREL  program  where 
the  parse-requests  are  replaced  by  a  call  on  a  COMPILE 
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subroutine,  which  is  given  both  the  name  of  the  parse-request 
and  the  request  body  and  uses  these  at  run  time  to  construct 
the  interpretive  table.  There  is  then  generated  a  call  on 
the  parser  to  initiate  the  parse-request-sequence.  PL/I 
code  is  generated,  which  when  executed  at  run  time,  arter  a 
successful  parse,  will  transfer  the  values  of  names  from  the 
APAREL  symbol  table  into  the  appropriate  PL/I  strings.  Code 
is  also  produced  that  handles  the  conditional  flow,  within 
a  parse-request  and  between  parse-requests,  which  depends  on 
the  successful-unsuccessful  indicator  returned  by  the  parse- 
request.  In  addition,  the  semantic  body  is  scanned  for  use 
of  the  TRANSLATION  string,  output  strings,  parse-request 
blocks,  etc.;  and  the  appropriate  modifications  and  additions 
to  the  APAREL  program  are  made.  At  the  conclusion  of  this 
first  pass,  the  output  is  compiled  as  a  normal  FL/I  program 
and  executed.  During  the  "second  pass"  the  COMPILE  statements 
are  threaded  through,  resulting  in  the  construction  of  a  run¬ 
time  SYMBOL_TABLE .  Then  control  is  passed  to  the  modified 
APAREL  program. 
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IX.  BASIC  DATA  STRUCTURE 


APAREL  is  basically  a  parser  driven  from  an  interpre¬ 
tive  form  of  the  syntax  de'  :ription  given  below.  Thus,  the 
system  data  base  is  molded  for  such  an  interpretive  environ¬ 
ment.  The  three  basic  data  structures  in  APAREL  are  de¬ 
fined  and  discussed  in  turn.  The  PL/I  declare  statement 
will  be  used  t-_  define  the  structures. 

A. _ SYMBOL  TABLE 

DECLARE  1  symbol_table  (  )  , 

2  literal  CHARACTER  (  )  VARIABLE, 

2  value  CHARACTER  (  )  VARIABLE, 

2  rule  BINARY  FIXED, 

2  option  CHARACTER  (  )  VARIABLE; 

In  the  interpretive  structure  all  references  to  a 
symbol  are  through  its  index  in  the  SYMBOL_TABLE .  The 
literal  character  string  contains  the  name  of  the  symbol 
represented  by  this  symbol- table  entry.  If  the  symbol  is 
acting  as  an  APAREL  name,  then  its  /alue  can  be  referenced 
by  the  value  subfield,  which  contains  a  character  string 
as  the  value  of  the  Symbol.  When  in  the  course  of  a  parse, 
a  successful  match  is  done  to  a  named  alternative  structure, 
the  name  of  the  alternative ,  or  its  index  number  if  no  name 
has  been  given  to  the  alternative,  is  assigned  to  the  OPTION 
subfield  of  the  entry  i”  the  SYMBOL_TABLE  corresponding  to 
the  name  of  the  alternative  structure.  The  rule  that  is 
named  by  this  litr ;al  is  pointed  to  in  the  sense  that 
SYMB0L_T ABLE. ROLE  points  to  the  location  in  the  SYNTAX  table 
at  which  this  rule  begins. 

I 

1 
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B.  SYNTAX 

DECLARE  1  SYNTAX  (  )  , 

2  TYPE  BINARY  FIXED, 

2  SYMBOL_INDEX  BINARY  FIXED; 

This  array  contains  the  interpretive  coae  that  drives  the 
parser.  Basically,  it  contains  the  parse-atom  type  as  an 
integer  in  the  TYPE  field,  and  (in  most  cases)  a  pointer, 
SYMBOL_INDEX  (an  index)  ,  to  the  symbol- table  entry  for  this 
parse  atom. 

As  an  example,  consider  the  APAREL  rule: 

::  SAM  :  JOE  (  ABE  :  MAY  ;  IKE  >  (ABE  j  DEF  >  :: 

During  the  second  pass ,  after  this  parse-request  has 
been  "compile*- /'  the  SYMBOL_TABLE  will  have  seven  entries. 
For  example,  the  first  entry  will  be  SYMB0L_TABLE(1) .LITERAL 
containing  the  character  string  "SAM",  SYMB0L_TABLE(1) .RULE 
containing  the  location  (1)  in  SYNTAX  of  this  rule.  Since, 
at  this  time,  the  value  of  SAM  is  null,  the  value  field  is 
set  to  the  null  string  and  the  option  field  to  zero. 
Similarly  JOE,  ABE,  MAY,  IKE,  ABC,  and  DEF  are  assigned 
slo~s  2,  3,  4,  5,  6,  and  7  in  the  SYMBOL_TABLE .  At  this 
point,  only  the  literal  field  is  set.  The  other  fields 
may  be  filled  in  further  as  additional  information  is 
gathered  from  the  "compilation"  of  later  parse-requests. 

Figure  1  illustrates  the  SYNTAX  entry  for  this  rule. 
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TYPE  SYMBOL  INDEX 


SYNTAX  (1) 

(2) 


LITERAL 

2  (JOE) 

Beginning 
of  Group 

3  (ABE) 

NAME 

. 

A  (MAY) 

End  of 
Group 

5  (IKE) 

Beginning 
of  Group 

NAME 

3  (ABE) 

or 

NAME 

7  (DEF) 

End  of 

Group 

End  of 

Rule 

1  (SAM) 

Note : 


Note : 


Note : 


Note : 


Note : 


Note: 


Note : 


namely  the  string  is  in 
SYMBOLJTABLE (2) . literal . 

symbol_index  has  the 
name  of  the  group. 


if  MAY  is  a  rule  name 
at  the  time  of  execution 
it  will  activate  the 
parse-request  or  else 
it  will  use  the  literal 
string  MAY. 


.n  the  end  of  group  is 
the  name  of  the  pro¬ 
cedure  (a  pointer  to 
the  symbol_table)  which 
will  be  used  if  the 
group  succeeds. 


no  group  name. 


marks  an  alternative. 


the  end  of  rule  contains 
the  rule  named  for  assign¬ 
ment  of  the  substring 
matched  if  the  parse- 
request  is  successful. 


Fig.  1 — Syntax  of  a  Rule 
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Appendix 

BNF  DEFINITION  OF  APAREL'S  SYNTAX  LANGUAGE 


<PA'\SE_KCObt  ST>  :  =  <PARS£_D!*l  tMlNATU.O<l»Ai<SF._NAME>  : 

<PAH  S£_AL  Tf-KNAT  I  VE_L  I  S  J  X?  A:<SC_DL  L  I  M  I  HA  n)K> 

<PAR SF_AL  TERN A  TI VE_L I S T>  :=  <P  AR  S*?_c  IK  VHM  T_L  I  S  T  >  ! 

<PARSE_£LF'vcUT_L!S1>  •  I  '  < P ARS t_ AL T ERN A Tl VE_L I S T> 
<PARSE_ELEVtNr_Llsr>  :=  <PA;>Sf:_FLc*E;«sT>  I 

<  ?  A  R  S  t _  E  L  t  ?'  E  N  T  >  ;  <  i>  A  P  $  E  _  T  I  £  _  -<  i  J  U  f  1 N  E  _N  A  M  E  >  i 
<P AK  SE_C LE  >v£: NT  ><ParS£_E Lt*‘'E:iT_L  I  ST  >  | 

< P A k  S E _ E L E  K E N  T  > . < "A R S E _ E  L E  k £  N T _ L I S 1  > 

CPARSE _l  l.£MENT>  :=  <PAkSE_AT  tiM>  |  <P  AP. Sc_  ;ROUf>> 

<»*ARSeI(.RGUP>  :=  '<'  <PARS£_ALTcRNAT  IVEJ.  I  ST>  •  >•  I 

•<•  <PaRSE  AME>  :  <parSE_AL  T  ER'J  A  r  I  V  E_L  I  s  r  >  »>' 

<P  All  SE_A  rOM>  :=  <  P  A  R  S  E  _  N  A  M l:  >  i  <TE  X  T _L  I  T  E  R  AL> 

C‘AKSE_NAME>  :=  <PL/1  IDENTIFIED 
<PARSE_[)FLIM1NATUR>  :: 

<PARSE_TlKC JtnuriNL_.\APE>  :=  CNAME  OF  A  PL/1  HIT  VALUED  FUNCTION  > 
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